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Abstract — We  describe  the  development  of  IRONSIDES,  an 
implementation  of  DNS  that  Ls  provably  invulnerable  to  remote 
code  execution  exploits  and  single-packet  denial  of  service 
attacks.  Our  experimental  results  show  it  to  be  over  three  times 
as  Fast  as  BIND,  the  most  common  implementation  of  DNS. 
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L  INTRODUCTION 

The  Internet  Domain  Name  System,  or  DNS,  is  an  essential 
component  of  internet  infrastructure.  Responsible  for  turning 
names  into  IP  addresses,  its  protocols  are  running  on  hundreds 
of  thousands  of  computers  all  over  the  world.  Designed 
originally  to  solve  a  problem  of  scalability  during  the  early 
days  and  rapid  growth  of  the  ARPAnet,  it  has  by  any  standard 
been  an  incredible  success. 

This  success,  however,  has  come  with  a  price.  Because 
DNS  originates  in  the  earliest  days  of  the  internet,  before 
security  issues  were  well  understood,  its  most  popular 
implementations  are  rife  with  security  vulnerabilities.  Patches 
are  typically  released  reasonably  quickly  after  flaws  are 
discovered,  but  some  time  lag  is  inevitable  and  there  is  no 
guarantee  that  an  overworked  system  administrator  will  apply 
the  patch  in  a  timely  fashion,  or  even  at  all.  Thus  DNS  servers 
around  the  world  can  be  crashed  by  hackers,  or  even  worse, 
taken  over  by  them. 

To  address  this  problem,  we  have  developed  a  DNS  server 
known  as  IRONSIDES  that  is  provably  invulnerable  to  many 
of  the  problems  that  plague  other  servers.  It  achieves  this 
property  through  the  use  of  formal  methods  in  its  design,  in 
particular  the  language  Ada  and  the  SPARK  formal  methods 
tool  set.  Code  validated  in  this  way  is  provably  exception- free, 
contains  no  data  flow  errors,  and  terminates  only  in  the  ways 
that  its  programmers  explicitly  say  that  it  can.  These  are  very 
desirable  properties  from  a  computer  security  perspective. 

IRONSIDES  is  not  only  stronger  from  a  security 
perspective,  it  also  performs  better  than  any  DNS  server  we  are 
aware  of.  It  provides  one  data  point  show  ing  that  one  need  not 
trade  off  reliability  for  performance  in  software  design. 


We  begin  with  an  overview  of  the  problem  IRONSIDES  is 
designed  to  solve.  We  then  discuss  why  we  believe  ihe  time  is 
ripe  for  formal  methods  to  play  a  role  in  improving  the  security 
posture  of  internet  infrastructure  software.  We  describe 
IRONSIDES,  our  experimental  results,  and  conclude  with  a 
summary  and  directions  for  future  work. 

1 1 .  The  Nature  of  the  Problem 
A  What  is  BIND? 

BIND  stands  for  the  Berkeley  Internet  Name  Domain 
server.  Originally  written  in  1984,  it  has  been  ported  to  a 
number  of  systems  and  compilers,  and  has  been  maintained  in 
the  public  domain  since  its  inception.  According  to  the 
Wikipedia  entry  on  DNS,  it  is  the  dominant  name  service 
software  on  the  internet. 

Just  how  popular  is  BIND?  According  to  one  source,  in 
2003  BIND  handled  about  85%  of  all  the  internet  DNS 
requests  [I].  A  more  recent  survey  of  over  1  million  sampled 
domains  showed  that  over  75%  are  running  BIND  [2].  Thus 
security  problems  in  BIND  would  seem  to  merit  the  most 
attention,  since  they  would  have  the  greatest  impact  Hackers, 
of  course,  know  this  quite  well,  and  would  naturally  focus  their 
efforts  on  BIND.  Since  BIND  is  open  source,  finding  its 
security  flaws  is  not  particularly  challenging  for  any 
experienced  hacker. 

We  note  parenthetically  that  numerous  alternatives  to  BIND 
arc  available,  including  implementations  bundled  with 
Microsoft  Windows. 

B,  DNS  Security  Vulnerabilities 

Because  the  DNS  protocols  and  implementations  were 
created  in  the  very  early  days  of  the  internet,  before  security 
issues  were  well- understood,  virtually  all  DNS  servers  running 
today  contain  significant  security  vulnerabilities.  The  problem 
is  particularly  acute  In  BIND,  due  to  three  factors:  a)  BIND 
was  the  first  implementation  of  DNS,  b)  BIND  is  written  in  C, 
a  language  with  no  security  features,  and  c)  RrND  is  open- 
source,  which  means  security  holes  can  quickly  be  identified 
and  exploited.  To  deal  with  these  problems,  the  latest  release 
of  BIND  (v9)  is  a  complete  rewrite  from  scratch.  It  is  a 
significant  improvement,  but  flaws  are  still  being  found. 
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Security  problems  with  BIND  are  particularly  problematic 
due  to  its  status  as  the  most  popular  (and  free)  DNS  software 
on  the  planet.  However,  they  are  by  no  means  limited  to 
BIND.  Windows  DNS  was  designed  and  implemented  much 
later  than  BIND  and  is  proprietary  software,  but  still  has 
numerous  security  vulnerabilities. 

C.  Types  of  Vulnerabilities 

Although  there  are  dozens  of  security  flaws  in  DNS 
software,  the  known  ones  can  be  classified  into  a  few  distinct 
types: 

■  DOS:  Denial  of  Service.  This  flaw  means  the  server 
can  be  crashed  by  a  client  sending  it  a  specially 
formatted  query.  The  query  is  not  formatted  in  a  w'ay 
that  the  server  expects,  causing  an  illegal  instruction 
error,  an  uncaught  exception,  or  similar  event  that  leads 
to  program  termination.  This  renders  domain  name 
service  inoperative  on  the  target  machine. 

*  RCE:  Remote  Code  Execution.  More  serious  than 
denial  of  service,  an  attacking  program  sends  a  non¬ 
standard  query  that  diverts  execution  flow  to  malicious 
code  supplied  by  the  attacker.  The  gives  the  attacker 
control  of  DNS  on  the  target  machine. 

*  Spoofing/cache  poisoning:  This  enables  attackers  to 
inject  incorrect  information  into  DNS  to  misdirect 
traffic  from  its  correct  destination  to  one  selected  by 
the  attacker. 

*  Protocol  weaknesses:  These  exploit  security  defects 
inherent  in  the  DNS  protocol  or  algorithms  themselves. 

D.  Current  Status  and  Impact  of  DNS  Security  Vulnerabilities 

lust  how  serious  are  DNS  security  (laws?  For  BIND,  as  of 
this  writing  an  analysis  of  the  security  vulnerabilities  at 
http://wwwhsc.org/  advisories  shows  a  total  of  45 
vulnerabilities.  Twenty-four  of  these  are  remote  denial  of 
service  attacks,  nine  are  remote  exploitation /execution.  The 
remaining  twelve  arc  weaknesses  in  cryptographic  algorithms, 
the  DNS  protocol  itself,  or  similar  problems  with  the 
algorithms  themselves  rather  than  their  implementation. 

The  statistics  for  Windows  DNS  security  flaws  are  more 
difficult  to  determine.  However,  our  examination  of  published 
Microsoft  Security  bulletins  from  the  past  five  years  found 
eight  related  to  Windows  DNS.  In  reverse  chronological  order, 
they  are: 

*  MSI  1-058  -  two  vulnerabilities,  one  denial  of  service 
and  one  remote  exploit 

■  MSI  1-030-  remote  code  execution 

*  MS  09-008  -  spoofing  vulnerability 

*  MS  08-037  -  spoofing  vulnerability  (2) 

*  MS  08-020  -  spoofing  vulnerability 

*  MS  07-062  -  spoofing  vulnerability 

*  MS  07-029  -  remote  exploitation 

*  MS  06-041  -  remote  exploitation  vulnerabilities  (4) 


This  gives  a  total  of  twelve  known  security  flaws  in  various 
versions  of  Windows  DNS. 

In  principle,  these  vulnerabilities  and  those  of  BIND  can  be 
removed  by  applying  the  appropriate  patches/code  updates.  In 
practice,  however,  updates  are  not  always  applied  in  timely 
fashion,  if  ever.  More  importantly,  since  there  is  no  claim  of 
formal  verification  for  either  of  these  implementations,  it  is 
likely  that  both  contain  further  as  yet  unknown  security  holes 
for  hackers  to  exploit. 

From  this  point  forward,  we  concern  ourselves  only  with 
the  security  and  performance  of  BIND.  For  a  comparison  of 
IRONSIDES  with  Windows  DNS,  the  reader  is  referred  to  [3]. 

IH.  Formal  Methods  as  a  Solution 

One  reason  security  flaws  (or  indeed  flaws  of  any  kind) 
exist  in  software  is  because  our  ability  to  reason  about  software 
has  lagged  far  behind  our  ability  to  write  it.  It  has  long  been 
known  that  in  principle  it  possible  to  prove  correctness  and 
security  properties  of  computer  programs.  But  in  practice,  the 
difficulties  in  doing  so  efficiently  have  proven  extremely 
challenging. 

Attempts  to  use  proof  techniques  from  mathematics  in 
software  design  belong  to  the  computer  science  discipline 
known  as  formal  methods.  For  most  of  computing  since  the 
days  of  the  internet,  the  use  of  formal  methods  for  all  but  the 
most  trivial  of  programs  has  been  either  impossible  or  grossly 
cost-ineffective.  The  result  has  meant  that  most  errors  are 
discovered  and  removed  from  software  via  pre-release  testing. 
Further  errors  are  either  discovered  by  users  or  exploited  by  the 
hacker  community,  with  the  results  being  repaired  in  post- 
release  patches.  This  describes  the  current  state  of  most 
modern  security  vulnerabilities,  and  DNS  vulnerabilities  in 
particular. 

A  Progress  in  Formal  Methods 

Fortunately,  our  ability  to  automatically  prove  program 
correctness  has  improved  significantly.  As  tools  have  become 
more  cost-effective  and  user  friendly,  the  scope  and  power  of 
software  for  which  formal  methods  can  be  applied  has  grown 
dramatically. 

For  example,  research  from  Microsoft* s  SLAM  project  was 
incorporated  into  releases  of  Windows  Vista.  Based  on  a 
formal  methods  approach,  Vista’s  device  driver  validation 
module  detects  if  drivers  linked  to  it  violate  certain  interface 
rules  [4j.  The  next  year,  Heitmeyer  and  Jeffords  [5]  reported 
the  successful  use  of  the  SCR  requirements  model  in  the  Deep 
Impact  probe  and  International  Space  Station  software. 
Implementing  the  Common  Criteria  for  Information 
Technology  Security  Evaluation  has  proven  fertile  ground  for 
formal  methods,  as  shown  by  Heitmeyer  and  others  [6]. 

In  2008,  Airbus  described  its  successful  use  of  the  SCADE 
system  to  automatically  generate  code  from  formal 
specifications  in  its  A34G-500/600  aircraft  [7j.  Sony  developed 
the  firmware  for  its  new  contactless  IC  cards  using  the  VDM++ 
and  VDMTools  relying  on  formal  methods  [8].  More  recently 
still,  the  Verisoft  project,  funded  by  the  German  Federal 
Ministry  of  Education  and  Research,  published  claims  of  proof 


of  correctness  of  a  real-time  operating  system  known  as  OLOS, 
designed  for  automotive  applications  [9]. 

We  have  taken  advantage  of  the  recent  progress  in  formal 
methods  to  construct  and  eventually  release  IRONSIDES,  an 
open-source,  provabiy  secure  implementation  of  DNS.  We 
now  turn  to  a  discussion  of  the  source  language  and  tool  set 
used,  and  then  discuss  its  functionality,  performance,  and 
security  properties* 

ft  SPARK:  A  Tool  for  Creating  Provabiy  Correct  Programs 

The  SPARK  language  and  toolset  from  Praxis  Critical 
Systems  Limited  is  used  in  the  creation  of  software  systems 
with  provable  correctness  and  security  properties  [10],  SPARK 
is  a  subset  of  Ada,  augmented  with  special  annotations.  These 
annotations  appear  as  ordinary  comments  to  Ada  compilers,  but 
are  visible  to  SPARK’s  pre-processing  tools  used  to  validate 
the  software*  SPARK  is  a  fairly  mature  technology  and  has 
been  used  on  several  projects  [11],  [12],  [13].  Accordingly, 
given  our  prior  institutional  experience  with  Ada  [14],  we 
chose  SPARK  and  Ada  as  the  platform  for  constructing  DNS 
software  that  would  not  be  subject  to  most  of  the  vulnerabilities 
that  afflict  DNS  implementations  currently  deployed  around 
the  globe. 

IV.  IRONSIDES;  FORMAL  METHODS  AND  DNS 

IRONSIDES  is  an  Ada/SPARK  implementation  of  the 
DNS  protocols.  Currently,  it  supports  only  authoritative  name 
service,  but  future  versions  are  expected  to  support  recursive 
queries*  We  are  also  in  the  process  of  adding  support  for 
DNSSEC,  the  protocol  that  adds  encryption  to  DNS  transaction 
to  further  reduce  vulnerability  to  spoofing  and  other  attacks 
[15]*  We  expect  full  support  for  DNSSEC  to  be  available  in  a 
future  release* 

IRONSIDES  consists  of  a  total  of  42  Ada  files,  comprising 
6480  lines  of  text.  Of  these,  4564  are  neither  blanks  nor 
comments.  Comments  include  746  SPARK  proof  annotations* 
about  a  12%  overhead  in  terms  of  source  lines. 

As  of  this  writing,  validation  of  IRONSIDES  requires  the 
generation  and  proof  of  6, 1 83  verification  conditions,  or  VCs. 
These  include  assertions  that  variables  always  remain  in  type, 


array  bounds  are  never  exceeded,  specific  pre-  and  post¬ 
conditions  of  procedures  are  always  true,  and  so  forth.  When  a 
VC  is  proved,  it  is  said  to  be  discharged.  Discharge  of  a  VC  is 
accomplished  through  a  multi-stage  process  using  the  SPARK 
automatic  theorem  proving  tools.  For  the  VCs  in  IRONSIDES, 
2,086  were  proved  by  the  Erst  stage  of  the  tools,  and  4,033  by 
the  second,  almost  99%.  The  remaining  1%  of  VCs  were 
sufficiently  complex  to  require  the  use  of  the  Alt-Ergo  theorem 
prover  [16],  built  into  SPARK  as  an  option  to  discharge  VCs 
that  the  other  tools  cannot. 

Software  validation  is  not  considered  complete  until  all 
VCs  are  discharged.  For  IRONSIDES,  the  complete  validation 
of  code  through  the  discharge  of  all  VCs,  from  their  initial 
generation  to  the  final  summary  report,  takes  3  minutes  6 
seconds  on  an  IBM  ThinkPad  X22G  Tablet  PC  with  8GB  of 
memory. 

As  a  result  of  this  process,  IRONSIDES  code  is  known  to 
be  free  of  uninitialized  values,  data  flow  errors  (e.g*  writes  that 
are  never  read  or  values  derived  from  incorrect  sources),  array 
bounds  errors,  and  all  runtime  exceptions*  This  renders  it 
invulnerable  to  single- packet  denial  of  service  attacks  and  alt 
remote  execution  exploits.  If  IRONSIDES  is  properly 
compiled  and  configured,  it  cannot  be  taken  over  as  a  result  of 
any  external  input,  no  matter  when  the  input  arrives  and  no 
matter  how  it  is  formatted.  Also,  it  cannot  be  crashed  and  all 
its  loops  are  guaranteed  to  terminate,  which  renders  it 
invulnerable  to  denial  of  service  attacks  that  rely  on  badly 
formatted  packets.  It  is,  as  far  as  we  know,  the  only  DNS  server 
to  make  these  claims. 


A  Experim  ental  Res  ults 

In  this  paper  we  compare  the  performance  of  IRONSIDES 
with  BIND  the  DNS  stress  testing  tool  ‘dnsperf*  [17].  Because 
IRONSIDES  is  still  in  its  early  stages  of  development,  it  does 
not  have  all  of  BIND’s  features.  Any  comparison  thus  needs  to 
take  these  differences  into  account*  Following  the  style  of  [18], 
we  show  a  comparison  of  IRONSIDES  and  BIND  in  Table  1 
below.  Footnotes  and  parenthetical  comments  for  BIND  are 
omitted  to  save  space. 


TABLE  1.  IRONSIDES  AKD  BIND  FEATURE  COMPARISON 


Server 


Authoritative  Recursive 


Recursion  Stave 

ACL  mode 


Caching  DNSSEC  TS8G  IPv6  Wildcard 


Interface 


sfiUi 

horizon 


BIND  Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Web, 

command 

line 

Y 

IRONSIDES  Y* 

N 

N 

N 

N 

in 

progress 

N 

Y 

N 

Y 

command 

line 

N 

■The  falkiwing  resource  record  types  are  ctiiteissJy  supported  A,  A  AAA,  CNAME,  MX.  NS,  FTR,  SO  A. 


Our  experimental  test  bed  for  comparing  BIND  and 
IRONSIDES  is  shown  in  Figure  1 : 


ACE  2600  Workstation 


Figure  L  Test  Bed  for  Comparing  DNS  Itti  pic  mental  ions 

"dnsperf  runs  on  a  Backtrack  5.0  client  virtual  machine. 
For  the  server  VM  we  used  Ubuntu  1  LG,  Testing  is  done  by 
starting  up  the  DNS  server  to  be  tested  and  then  running 
dnsperf*  Only  one  DNS  server,  server  VM,  and  client  VM  are 
active  at  any  one  time. 

Since  the  purpose  of  the  experiment  is  to  measure  the 
computational  performance  of  the  server,  all  VMs  are  loaded 
on  the  same  computer,  in  this  case  an  ACE  2600  Workstation 
with  8GB  of  RAM.  Using  the  same  computer  for  client  and 
server  eliminates  the  effect  of  network  latency,  'dnsperf 
issues  queries  over  the  standard  DNS  port  to  whichever  server 
is  listening.  The  server  in  turn  responds  as  appropriate.  At  the 
end  of  a  run,  the  tool  generates  a  performance  report. 

For  each  server,  we  performed  three  test  runs  and  then 
averaged  the  results*  The  performance  of  BIND  and 
IRONSIDES  is  shown  below: 


DNS  server  performance 
(queries/m$) 

BIND  i  IRONSIDES 


'   

Figure  2,  BIND  and  I RO  NS  I  DO  $  Pe  dorm  an  cc 


B.  Analysis 

IRONSIDES  is  over  three  times  faster  than  BIND  on 
Linux.  Given  IRONSIDES’  superior  security  posture,  we  find 
these  results  significant*  They  show  that  one  need  not  sacrifice 
security  for  performance  in  software  design. 

In  fact,  it  should  not  be  that  surprising  that  there  are  at  least 
some  instances  in  which  the  use  of  formal  methods  can 
improve  performance.  Data  flow  analysis,  for  example,  can 
identify  redundant  or  ineffective  statements  that  generate 
unnecessary  code.  Code  that  has  been  proven  except  ion- free 
no  longer  needs  run-time  bounds  checking,  so  that  code  can  be 
eliminated  as  well 

On  the  other  hand,  there  are  also  cases  where  total  reliance 
on  formal  methods  negatively  impacts  performance.  Given  the 
current  state  of  the  art  in  formal  methods  tools,  it  continues  to 
be  appropriate  to  allow  programmers  the  flexibility  to  override 
warnings  of  unproven  properties  when  they  believe  the 
tradeoffs  are  worth  if  This  is  especially  true  if  they  themselves 
can  see  that  certain  properties  hold,  even  when  tools  cannot 
make  that  determination. 

For  example,  DNS  queries  return  data  of  varying  size.  The 
use  of  dynamically  allocated  data  structures  significantly 
complicates  formal  analysis,  and  renders  the  ability  to  bound 
the  maximum  storage  required  for  a  program  impossible.  For 
this  reason,  SPARK  requires  all  data  structures  to  be  statically 
allocated  [9].  Thus  routines  that  return  varying  amounts  of 
data  use  an  output  data  structure  of  fixed  size,  defined  at 
comp ile- time  as  a  known  upper  limit. 

Data  flow  analysis  of  such  structures,  however,  requires 
that  all  such  storage  be  explicitly  initialized,  to  ensure  that  stale 
data  is  never  passed  back  and  that  undefined  values  are  never 
used.  Arrays  in  SPARK  in  particular  are  treated  as  entire 
variables.  Thus  initializing  an  array  in  a  loop  with  a  statement 
like  A(I)  0  is  considered  a  dataflow  error,  because  only  part 
of  A  is  set*  Instead,  the  use  of  Ada  aggregates  is  required  to 
eliminate  dataflow  errors. 

This  uprecauli°nariy  principle”  can  have  significant 
performance  consequences.  If  only  one  entry  of  an  array  is 
filled  and  returned  by  a  procedure,  but  128  entries  must  be 
explicitly  initialized,  this  is  inefficient  and  wasteful.  Thus  in  a 
few  cases  throughout  the  code  where  such  things  matter,  we 
removed  aggregate  initialization,  with  explicit  instructions  to 
the  tools  to  ignore  all  related  dataflow'  errors.  We  then 
manually  inspected  the  code  to  ensure  this  did  not  introduce 
any  security  vulnerabilities*  For  example,  by  keeping  a  simple 
index  variable  to  indicate  the  upper  limits  of  useful  data,  it  can 
be  shown  by  inspection  that  undefined  or  stale  data  is  never 
read.  Employing  this  optimization  improved  the  performance 
of  IRONSIDES  by  29%. 

Our  experience  indicates  that  allowing  users  to  override 
formal  proof  requirements  when  appropriate  is  an  important 
feature  that  current  formal  methods  tools  should  always 
support.  Since  such  overriding  is  optional,  users  in 
environments  where  manual  verification  of  source  code  is 
deemed  too  risky  can  revert  to  the  original,  formally  verified 
source  code  at  some  cost  in  performance* 


C  Resistance  to  Denial  of  Service  Attacks 

IRONSIDES  is  invulnerable  to  denial  of  service  attacks 
caused  by  badly  formatted  packets  that  raise  exceptions*  But 
terminating  a  server  is  not  the  only  way  to  deny  service*  If  the 
server  can  be  thrown  into  an  infinite  loop,  service  is  just  as 
effectively  denied.  IRONSIDES  is  invulnerable  to  this  form  of 
service  denial  as  well,  because  the  tools  employed  help  prove 


that  all  of  its  85  loops  terminate.  This  is  accomplished  by 
using  loop  invariant  assertions  to  show  that  loop  variables 
monotonically  increase  and  have  an  upper  bound.  This  is  not 
accomplished  automatically  by  SPARK,  but  with  appropriate 
loop  assertion  annotations  added  by  the  programmer  SPARK 
can  assist  in  showing  these  properties  to  be  true. 

For  example,  consider  the  code  below: 


--  Amount  Trimmed  is  used  to  guarantee  we  don't  end  up  in  an  infinite  loop 

while  Answer_Count=G  and  Amount _Trimmed<RR_Type , Wires tringType ■ Last  and 
Natural (Character 1 Pos (Current  Name (Current_Name 1  First ) ) ) /=0  and 
Current_Qname_Location  <-  DNS_Types  * QNAME  FTR  RANGE (Gutput  Bytes )  loop 
- — if  assert  Answer_Count™0  and  Amount_Trimmed>=0  and 
Amount  Trimmed<RR_Type - Wi re 3 tringType *  Last 
and  Output_Bytes  <™  DNS_Types . Pa eke t_Length_Rangef Last 
and  Current_Qname_Location  <=  DNSTypes .QNAME _PTR_RANGE (Out put  Bytes ) ; 
TrimName ( 

=>  Currervt_Name , 

*^>  Trimmed^Name, 

=>  Current_Qname_Location, 

New  Qname  Location) ; 


Domainname 
Trimmed_Name 
Qname_Loca t ion 
Ne wQnameLoc  a  t i on 
Create_Response_SOA( 
Start_Byte  => 

Doma  inname  => 

Qname_Location  => 

Output_Packet  -> 

An  s  we  r__Count  => 

OutputBytes  => 

CurrentName  :=  Trimmed 
Current  Qname  Location 


Start_Bytef 

Trimmed_name, 

New_Qname_Location, 

Output_Packet, 

Answer  Count, 
Output_Bytes) ; 

Name; 

**  New  Qname  Location; 


Amount^Trimmed  ;=  Amount  JT  rimmed  + 

Natural (Character1 Pos ( Domainname (Domainname 1  First) ) +1) 
end  loop; 

Figure  3.  Using  loop  invariants  to  prove  termination 


SPARK  annotations  begin  with  .  Here  the  annotations 
are  loop  invariants  that  serve  as  both  a  postcondition  for  one 
part  of  the  loop  and  as  preconditions  for  the  next.  In  this  case 
the  tools  prove  that  Amount  Trimmed  is  at  all  times  both  non¬ 
negative  anti  below  a  constant  upper  bound.  They  also  show 
that  A mount_Tri turned  is  not  modified  elsewhere  in  the  loop. 
Given  these  properties  and  the  last  line  of  the  loop,  we  can 
conclude  that  Amount_Trimmed  is  monotonically  increasing, 
therefore  the  loop  terminates. 

Note  that  without  the  use  of  this  variable  and  the  proof 
annotations,  we  could  not  prove  loop  termination*  This  would 
leave  open  the  possibility  for  the  other  termination  conditions 
to  never  be  reached,  something  that  could  be  exploited  under 
the  right  circumstances  to  deny  service  through  an  infinite  loop. 

While  IRONSIDES  is  not  completely  resistant  to  packet 
flooding,  neither  is  any  other  program.  Since  it  performs 
significantly  better  than  BIND,  however,  at  a  minimum  it  can 
handle  as  much  or  more  flooding.  Additionally,  IRONSIDES 
contains  two  features  not  related  to  formal  methods  designed  to 
make  it  more  resistant  to  flooding-based  denial  of  service 
attacks.  First,  the  number  of  simultaneous  TCP  connections  is 


limited  by  a  user-tunable  parameter.  Additionally, 
IRONSIDES  enforces  a  socket  timeout,  to  prevent  an  attacker 
from  holding  a  connection  open  for  a  long  period  of  time. 

£).  Lessons  in  Humility 

Despite  the  use  of  formal  proofs  in  the  determination  of 
IRONSIDES  security  properties,  a  cautionary  talc  remains  in 
order*  It  is  always  worth  remembering  that  the  quality  of 
software  written  in  a  high  level  language  is  only  as  good  as  the 
quality  of  the  compiler  that  generates  code  from  it*  For  at  least 
one  combination  of  operating  system,  compiler,  and 
optimization  level,  we  were  able  to  replicate  a  case  where  a 
fully  validated  version  of  IRONSIDES  still  crashed  with  an 
exception,  due  to  a  code  generation  error  in  the  Ada  compiler 
(Free  Software  Foundation  GNAT)  shipped  with  Ubuntu. 

Clearly  blame  for  bugs  of  this  nature  cannot  be  laid  at  the 
feet  of  the  tools  vendors,  since  they  are  not  responsible  for 
public  domain  compilers.  Nonetheless,  the  mere  existence  of 
such  errors  is  somewhat  disturbing.  Until  formal  methods  have 
progressed  sufficiently  to  prove  the  correctness  of  compilers 


themselves,  practitioners  should  continue  to  exercise  caution  in 
how  they  compile  and  test  validated  software. 

It  remains  true  that  the  use  of  formal  methods  and  the 
SPARK  tools  in  particular  produced  results  that  are  both 
impressive  and  humbling.  Both  the  authors  are  experienced 
software  engineers,  having  written  compilers,  introductory 
programming  environments,  circuit  emulators,  and  other  non¬ 
trivial  software  systems.  In  addition  to  over  40  years  combined 
computer  science  teaching  experience,  we  have  consulted  for 
both  industry  and  government. 

But  despite  all  our  experience  and  credentials,  the  formal 
methods  tools  we  employed  caught  boundary  conditions  and 
potential  problems  that,  while  unlikely  to  arise  in  practice,  were 
still  in  principle  things  we  should  have  detected  on  our  own  but 
did  not  These  include  array  subscript  overruns,  unusual  but 
possible  boundary  conditions  like  single- letter  domain  names, 
and  so  forth.  Had  the  tools  not  flagged  these  as  possible  run¬ 
time  errors,  they  could  have  become  security  flaws  similar  to 
those  in  BIND. 

V.  Conclusions  and  Future  Work 

We  began  this  project  concerned  about  the  large  number  of 
security  vulnerabilities  in  &  vital  component  of  internet 
infrastructure,  the  Domain  Name  System.  We  had  reason  to 
believe  that  formal  methods  had  progressed  to  the  point  where 
they  could  now  be  employed  to  produce,  for  the  first  time,  a 
public-domain  version  of  DNS  with  proven  security 
properties.  We  believe  we  were  successful  in  this  objective. 

In  the  course  of  developing  IRONSIDES,  we  discovered  that 
certain  tradeoffs  can  be  made  to  improve  performance  at  the 
expense  of  formal  verification  assurance.  But  in  general,  our 
work  clearly  shows  that  it  is  absolutely  possible  to  obtain  both 
improved  performance  and  improved  reliability  in  software 
design,  provided  security  considerations  and  formal  methods 
are  incorporated  at  the  very  beginning  of  the  process. 
IRONSIDES  runs  over  three  times  faster  than  BIND  under  the 
version  of  Linux  wc  tested.  Unlike  BIND,  it  cannot  be 
subverted  or  crashed  through  bad  packets. 

For  a  truly  fair  comparison  with  BIND,  however,  we  need  to 
incorporate  more  features  into  IRONSIDES.  In  addition  to 
support  for  DNSSEC,  future  plans  include  support  for 
recursive  queries,  GUI  and  web  interfaces  (IRONSIDES  is 
currently  command  line  only)  and  other  more  advanced 
features.  Future  work  could  also  include  testing  under  more 
operating  systems  and  testing  under  actual  network  loading. 
Finally,  we  believe  other  implementations  of  internet  protocols 
that  suffer  from  security  flaws  could  benefit  from  the  approach 
described  here. 

IRONSIDES  is  in  the  public  domain,  and  will  be  distributed 
free  of  charge. 
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